Welcome to ECroPS’s documentation!¶
Indices and tables¶
Packages code documentation:
ECroPS Manual¶
Ecrops Manual
This is the manual of the ECroPS model platform. The present document refers to ECroPS version 1.7.0 (released May 2024). More information regarding the agronomic description of the models and the parallelization of the model can be found in the ECroPS technical report
What is ECroPS¶
ECroPS (Engine for Crop Parallelizable Simulations) is a software platform to build and run agronomic models. It was developed by JRC, Unit D5.
Implemented models¶
The first agronomical model implemented in the platform is the Wofost model (version 5.3.1). See Wofost documentation here: https://wofost.readthedocs.io/en/latest/# For writing the Wofost implementation, we started from the PCSE software developed by Wageningen University and Research. See PCSE documentation here: https://pcse.readthedocs.io/en/develop/ . PCSE contains a full python implementation of Wofost. We extracted a part of the Wofost modules and we re-coded them in the ECroPS platform, saving most of the algorithmic part of the code, but changing many aspects like the way variables are stored and the simulation cycle. At the end of the conversion, a validation test was made to verify the correctness of the new implementation in terms of simulation results.
It was then implemented the WARM model (version 1.9), originally developed by professor Roberto Confalonieri (Cassandra Lab at University of Milan). WARM was written in C# in the Bioma platform, so the code was re-written from scratch. In addition, in this case it was performed a validation test phase to verify the correctness of the new version. See WARM documentation here: http://cassandralab.com
Published software¶
Since October 2022 eCroPS is published on the JRC Github page, at this address: https://github.com/ec-jrc/ecrops. In July 2024 it is updated to version 1.7.0 It is published under license EUPL 1.2. The published software covers the core engine and the Wofost/WARM implementations (package ecrops), plus an example of python console program to launch a simulation (folder EcropsWofostExampleConsole) as described in section ‘ECroPS model direct run’ of the present manual.
Technical implementation of the platform¶
In this platform, we describe the agronomical model as a succession of steps to be executed. Each step represents the minimal algorithmic part of the model. Steps are daily based, and they are executed in a cycle for a period between a start and an end date, provided in the configuration. The engine of the ECroPS platform is designed to work considering model’s steps, using configuration files to define the steps to execute and execution order. The steps are executed one after the other for the desired time iterations. The platform has no limitations for the number of steps or for the execution order.
More than that, the platform offers the possibility to load dynamically the steps, to define variables in dynamic manner, through configuration files (all configuration files are XML).
The model variables are defined inside a “status” variable, which is generated by the initialize method and then updated and returned by every step in the model.
Workflow of the ECroPS engine¶
The ModelEngine class is used to run the ECroPS model. When an instance of this class is created, it reads the configuration from a provided configuration file. This file defines the structure of the model execution in terms of steps to be executed, input data, and output variables. The class has several properties that define the driving variables, the instructions to initialize the status variables, the steps to run, and the output variables.
The simulation cycle is divided into three parts: the initialize method checks that the required driving variables are present and initializes the status variables with the provided input data; the executeStep method performs the simulation by calling the steps in the correct order for each day in the cycle; and the finalize method returns the calculated output variables.
The status of the model and its variables are stored in a “status” variable, which is modified by each model method. This variable is created by the initialize method and returned to the caller. It is the caller’s responsibility to manage the status variable and pass it to the executeStep and finalize methods as needed. This approach allows the caller to have full control over the status variable and perform custom tasks.
To use the ModelEngine class, a caller can follow the generic workflow:
Create a ModelEngine instance with the config file:
model = ModelEngine(config_file)Initialize the model with the required input variables:
status = model.initialize(timedependantvariables, drivingVariables, allparameters, first_day, simulation_start_day, simulation_end_day)For each simulation cycle, run the executeStep method with the current status:
status = model.executeStep(status)After the last simulation cycle, run the finalize method to get the output:
result = model.finalize(status)
The ModelEngine class can be used in different “run modes” that define which steps to execute. This allows the same model to be run in slightly different ways.
The configuration file contains:
the instructions to initialize the status variables (property initVariables)
(optional) the instruction to initialize the driving variables
the steps to run (property Workflows)
the list of variables to return as output (property Workflows)
The simulation cycle is divided in 3 parts:
the initialize method initializes the status variable from the property initVariables and the provided input data
the executeStep method performs the simulation by calling the steps in the correct order for every day in the cycle. For every day between simulation_start_day and simulation_end_day, if requested, the method populates a dailydetails array with the daily value of the output variables
the finalize method returns an array with output variables calculated after the last time interval executed
The model’s status and variables are all contained in a variable called “status”, which is modified by every model method. The status variable is NOT contained in the ModelEngine class: it is created by the initialize method and returned to the caller. The status is a required input of both executeStep and finalize methods. Every call to the executeStep method updates the status with the variable values calculated inside the step. It is duty of the caller to manage the status variable properly. This approach allow the caller to have a full control of the status variable to perform specific tasks.
Here the generic workflow of the caller:
model = ModelEngine(config_file)
status=model.initialize(timedependantvariables, timeDependantVariableColumn, drivingVariables, allparameters, first_day, simulation_start_day, simulation_end_day)
for every step of the simulation cycle:
status=model.executeStep(status)
result=model.finalize(status)
The input data of the model, passed inside the ‘initialize’ method, can be distinguished in three types and so three distinct arguments are passed to the method:
argument ‘timedependantvariables’: the time dependant variables are all the input variables that change value according to the time step, typically the weather data.
argument ‘allparameters’: dictionary containing all the parameters of the model. The keys of the dictionary are the crop identifiers
argument ‘drivingVariables’: the driving variables are all the variables that defines the configuration of the simulation to run, for example the crop to be run, the years to be run, the latitude and longitude of the simulated location, the soil properties of the location. In other words, the driving variables contains all the input data except the time dependant variables and the model parameters.
- The reading of the workflow is done in the constructor method of the ModelEngine class. Example:
model = ModelEngine(“my_workflow_file.xml”)
The workflow can be executed on more than one “run mode”. A “run mode” defines the steps to execute and can be used when the same model should be executed in slightly different ways, as, for example, adding or not adding a specific step. The reading of the workflow file is done at the beginning of the workflow, since that files defines the structure of the model execution in terms of steps to execute, input data and output variables. See section “Description of the workflow configuration file”.
The “initialize” method of the ECroPS engine initialize the “status” variable, by using all the inputs defined in the “Init” section of the workflow file. For example, if in the “Init” section is present this line
<Variable name="LAT" source="drivingVariables['LAT']" />
then the engine executes this line of code
status.LAT=drivingVariables['LAT']
so it instantiates a new variable called “LAT” in “status” and set its value to the value get by executing the instruction
drivingVariables['LAT']
where drivingVariables is one of the arguments of the “initialize” method.
Moreover, the “initialize” method checks that all the drivingVariables defined in the configuration file are set. In case one is missing an exception is thrown. The drivingVariables dictionary contains all the driving variables (e.g. the year and the crop to simulate, the soil data,…) Finally, the “initialize” method allow to pass to the engine the time dependant variables (usually the daily weather data). The time dependant variables are packed as a 2-dimensional array, called ‘timedependantvariables’, where the first dimension specifies the variable (e.g. the weather variable), the second dimension specifies the time step (e.g. the day). The names of the variables of the first dimension are specified in the property ‘timeDependantVariableColumn’: this is a dictionary containing the names of the variables and their relative column number in table ‘timedependantvariables’. Example:
timeDependantVariableColumn = {'TEMP_MAX': 0, 'TEMP_MIN': 1, 'IRRAD': 2, 'RAIN': 3, 'WIND': 4, 'RH': 5, 'E0': 6, 'ES0': 7, 'ET0': 8}
In this example, the temperature max (TEMP_MAX) is in the first column of the table timedependantvariables.
The “executeStep” method of the ECroPS engine runs all steps for specific run mode, in the defined order, for every value of status.day property when
status.simulation_start_day <= status.day <= status.simulation_end_day
status.day is incremented by 1 day at the end of the method.
The first value of status.day is the argument first_day of method initialize.
For every step, the “status” variable is set as an input of the step, is updated by the step and returned to the engine. Here the “executeStep” method workflow:
The current time interval counter (variable status.day) is set equal first_day
if current time interval counter is between “simulation_start_day” and “simulation_end_day”:
if current time interval counter is equal to “simulation_start_day”:
for each step, call step’s “setparameters” method
for each step, call step’s “initialize” method
if current time interval counter is greater than “simulation_start_day”:
for each step, call step’s “integrate” method
for each step, call step’s “runstep” method
if variable “ReturnDailyDetails” is True, add the current time interval output variables to the “status.dailydetails” variable
add 1 day to the current time interval counter
The “finalize” method of the ECroPS engine generates an array with output variables calculated after the last time interval executed and returns it. To do so, it uses the output variables definition read from the workflow file.
Description of the methods of a step¶
Each step must have a well-defined structure, to be properly managed by the platform. In particular, each step need to be implemented like a class with specific methods, like described below:
initialize – has the role to initialize the step data, for example the status variables used in the step (it is called only before executing the step for the first time)
setparameters – prepare the parameters necessary for the step run (it is called only before executing the step for the first time)
integrate – has the role to merge the values of the previous time interval before the calculation of the current time interval step operations.
runstep – has the role to execute all the step’s operations
getparameterslist – returns the list of the parameters managed by the step
getinputslist (new from version 1.7.0) – returns the list of the inputs needed by the step
getoutputslist (new from version 1.7.0) – returns the list of the outputs calculated by the step
The class can implement any other methods, but the previous list of methods are mandatory for the correct run of the engine.
(new from version 1.7.0) The step class should be an implementation of the ecrops.Step class, defined in the ecrops package. ecrops.Step is an abstract class that defines, as abstract methods, the methods listed above.
Each implementation of methods initialize, setparameters, integrate and runstep should accept as argument the status variable and return the updated status variable.
The trivial example is:
def initialize(self,status):
#do something on the status
return status
Description of the workflow configuration file¶
The main configuration file of the platform is the workflow configuration XML file. Inside the file, it is possible to configure:
Initial variables: the input variables of the model simulation
Driving variables: (optional) the definition of the driving variables set in the ‘drivingVariables’ argument of the initialize method of the Engine. The driving variables could be used to define the values of the initial variables
Steps and their order: the logics to be simulated
Output variables: the output variables to be returned to the caller
In the next paragraphs, it is presented the configuration that can be present inside the XML workflow configuration file.
The section Init (defined by tag Init) contains the definition of the variables that will be initialized at the start of the simulation. These are the attributes of the tag Variable:
name: describes the name of the variable to be created. The variable will be created as attribute of the status property using the provided name. For example is name is ‘myvar’, it will be created a variable status.myvar = value provided by source attribute
source: describes the way to retrieve the value for the variable. The source represents the way the Engine can get the variable value from the input data. Input data include arguments drivingVariables, timedependantvariables, allparameters, first_day, simulation_start_day, simulation_end_day. Alternatively, the value of the variable can be directly written in the workflow file. Any valid python expression is valid as a value.
There is no limits for the number of tag Variable inside the Init section.
Examples of input variable definitions:
<Variable name="V" source="’my string’" />
In the sample above, the value of the variable is equal to the constant ‘my string’.
<Variable name="V" source="57" />
In the sample above, the value of the variable is equal to the constant 57.
<Variable name="V" source="first_day" />
In the sample above, the value of the variable is equal to argument ‘first_day’.
<Variable name="V" source="drivingVariables['LAT']" />
In the sample above, the value of the variable is retrieved from the element ‘LAT’ from the dictionary with the name drivingVariables).
<Variable name="V" source="0 if drivingVariables['DEPTH'] <= 0 else drivingVariables['DEPTH']" />
In the sample above, the value of the variable is 0 if the value of the element ‘DEPTH’ from the drivingVariables is <=0, otherwise it is equal to the value of ‘DEPTH’).
The section DrivingVariables (defined by tag DrivingVariables) contains the definition of the driving variables that are passed to the model inside the Initialize method of the ecrops ModelEngine. The driving variables are all the variables that defines the configuration of the simulation to run, for example the crop to be run, the years to be run, the latitude and longitude of the simulated location, the soil properties of the location,… In practice, the driving variables contains all the input data except the time dependant variables and the model parameters.
Example:
<DrivingVariables>
<DrivingVariable name="YEAR" description="Year" unitofmeasure="" type="numeric" />
<DrivingVariable name="DURATION" description="Number of days to run" unitofmeasure="" type="numeric" />
<DrivingVariable name="Crop" description="Crop" unitofmeasure="" type="numeric" />
<DrivingVariable name="LAT" description="Latitude" unitofmeasure="degrees" type="numeric" />
....
The DrivingVariable section is optional. Driving variables do not need to be explicitly listed in the section. Adding this explicit list to the configuration file allows the engine to verify all the necessary variables where passed to the engine inside the Initialize method. If the section is not present in the workflow configuration file, the check is not performed. Otherwise, if the section is present, the engine, inside the Initialize method, checks that all the declared driving variables are present in the ‘drivingVariable’ dictionary passed as argument of the Initialize method. If a variable is not present, an exception is thrown and the model does not proceed.
The driving variables can be accessed using the format
`drivingVariables['var_name']`
The driving variables can be used to initialize the Variables of the Init section, as in the example below:
<Init>
<Variable name="LAT" env="locals" source="drivingVariables['LAT']" />
....
These are the attributes of the tag DrivingVariable:
name: the name of the driving variable.
description: the description of the driving variable.
unitofmeasure: the unit of measure of the driving variable.
type: the type of the driving variable. Could be:
numeric
boolean
string
file: the path to a file containing some values
There is no limits for the number of tag DrivingVariable inside the DrivingVariables section.
The section Workflow (defined by the node Workflow) allows to configure the steps for a workflow and the output variables of the workflow. This tag must have two attributes:
name: specifies the workflow name
run: gives the possibility to switch off/on the execution of a workflow. Two values are allowed for this attribute:
ON: workflow will be executed
OFF: workflow will be ignored
The subsection Steps (child of the Workflow node) contains the (unlimited) list of the steps of the model. Each step is identified by a Step node, like follow:
<Step>ECroPS.co2effect.LinkCo2DataToAssimilation|LinkCo2DataToAssimilation</Step>
The node value contains two elements, separated by character ‘|’:
the reference to the file that contains the class that implements the step, represented by its python path including the package name
the name of the class that implements the step
The subsection Output (child of the Workflow node) contains the (unlimited) list of the output variables of the model. Different workflows can return a different set of outputs, and this is the reason why this sub-section is defined under the workflow node. Each output variable is identified by a Variable node, like follow:
<Variable source="status.states.DVS" name="POT_DVS" description="Potential DVS "/>
<Variable source="status.vernalisation.DOV.timetuple().tm_yday" name="POT_JDOV" description="Potential Julian day of vernalization end "/>
The Variable node must have three attributes:
source defines the variable name or a method to retrieve the value for the output variable starting from the model’s internal status. A variable to be extracted as output should belong to property ‘status’, so the source should start with ‘status’. E.g. ‘status.weather.RAIN’’
name identifies the output variable
description textual description of the variable
Dynamic classes loading¶
As described in the previous paragraphs, the step configuration (see the Step tag) allows to define a complete path for the python class to run: this means it is possible to specify the physical path and the class name that implements the step.
<Step>ECroPS.co2effect.LinkCo2DataToAssimilation|LinkCo2DataToAssimilation</Step>
Considering our example, the application searches the file LinkCo2DataToAssimilation.py into the path /ECroPS/co2effect. Inside the file, it should be present the class LinkCo2DataToAssimilation. The content of the tag Step must follow the convention:
<Step> path of the python file |name of the class that implement the step</Step>
Daily details managements¶
Besides the final output variables returned by finalize method, the model engine can also fill and return a ‘daily details array’, where the engine saves the output variables at the end of every simulation time interval. So that the caller can save and analyse the behaviour of each output variable during the simulation. The daily details is particularly useful when analysing a single simulation output. The array can become huge, so it is recommended to disable it for batch simulations. To enable the ‘daily details array’, the Boolean property ‘ReturnDailyDetails’ of ModelEngine should be set to True. To retrieve the daily details array at the end of the simulation, it is sufficient to read property status.dailydetails.
Another property, called ‘PrintDailyDetails’, manages the print of the daily details. When set to true, the ModelEngine prints the daily details directly to the output console (standard output). To print the daily details to a file, the user should set the boolean property ‘PrintDailyDetailsToFile’ to true and set the property ‘PrintDailyDetails_OutputFile’ to the desired output file path.
Example of usage (returning but not printing daily details):
#initialize model
w = ModelEngine("Workflow.xml")
#return daily details
w.ReturnDailyDetails = True
# do not print automatically daily details
w.PrintDailyDetails = False
#....
#execute model
#....
#read the daily details
details=status.dailydetails
Example of usage (returning and printing daily details to a file):
#initialize model
w = ModelEngine("Workflow.xml")
#return daily details
w.ReturnDailyDetails = True
# print automatically daily details to file 'output.csv'
w.PrintDailyDetails = True
w.PrintDailyDetailsToFile = True
w.PrintDailyDetails_OutputFile = 'output.csv'
#....
#execute model
#....
#read the daily details
details=status.dailydetails
10-days details managements¶
Similarly to what explained in daily details management paragraph, it is possible to configure the model to return the details of the simulations at the end of every ‘dekad’: a ‘dekad’ is a period of circa 10 days defined as the first 10 days of the month, the second 10 days of the month, and the last days of the month starting from day 21.
1 - 10 first dekad of the month
11 - 20 second dekad of the month
21 - end-of-month third dekad of the month
As for the daily details, the resulting array can become huge, so it is recommended to disable it for batch simulations. To enable the ‘dekadal details array’, the Boolean property ‘ReturnDekadalDetails’ of ModelEngine should be set to True. To retrieve the dekad details array at the end of the simulation, it is sufficient to read property status.dailydetails. In this case the status.dailydetails object will contain only values for the 10th , the 20th and the last day of the month. If both ‘ReturnDekadalDetails’ and ‘ReturnDailyDetails’ are set to true, the daily results will be returned.
To print the dekad values, it should be used the property ‘PrintDailyDetails’ already described in the daily details managements paragraph. Also, it is possible to use the properties ‘PrintDailyDetailsToFile’ and ‘PrintDailyDetails_OutputFile’ as described in the previous paragraph to plot dedak output to file.
How to add a step into a model workflow¶
To add an existing step in a model workflow, the user should add the step definition in the XML workflow file, inside the ‘Workflow’ section, in the desired position. The user should ensure all the input required by the step are provided either by the previous steps, or are defined as variables in the Init section.
How to add a new step to an existing model¶
This is the procedure for adding a new step into an existing model:
Create a python class (like described in paragraph “Description of the methods of a step”) and place this new class into a valid python project. The class could be added directly to the ecrops package, but it is not mandatory.
Put the line of the new step into the desired position (like described in paragraph “Description of the workflow configuration file”) inside the workflow configuration file of the model. If the class is in a new python package, that package should be imported in the calling python code.
Example: the user creates a new step called ‘MyAlgorithm’ in a python package called “mypackage”. The class code, defined in file ‘MyAlgorithm.py’, is the following.
from ecrops.Step import Step
class MyAlgorithm(Step):
"""MyAlgorithm ecrops step"""
def getparameterslist(self):
return {}
def getinputslist(self):
return {}
def getoutputslist(self):
return {}
def setparameters(self, status):
return status
def initialize(self, status):
return status
def runstep(self, status):
return status
def integrate(self, status):
return status
The project structure is:
–> mypackage
——> __init__.py
——> MyAlgorithm.py
The project should be built as a valid package, called ‘mypackage’. The package should be imported by the python script that launches the model simulation. To include the MyAlgorithm step in the workflow configuration file, the user should add this line:
<Step>mypackage.MyAlgorithm|MyAlgorithm</Step>
If the new step is using some input variable not already present in the model, it is necessary to define it into the workflow configuration file (see the paragraph “Description of the workflow configuration file” – initial variables section).
(new from version 1.7.0) If the step does not extend class ecrops.Step an error will be triggered at the loading of the workflow.
ECroPS model direct run¶
An ECroPS model can be run directly from a python ‘main’ program, by following the example provided in project “EcropsWofostExampleConsole”. Inside the project, there is a “main.py” script that shows the steps to be done. We recommend to have a look at the script and try to execute it to familiarize with the ECroPS engine.
Initialize Wofost ECroPS implementation by reading the workflow file
Get all available run modes, as defined in the workflow file
Define basic input data (year, location data, crop,co2concentrations,…), the soil data and the sowing date-associated
Read the weather data (in this case from a CSV file) into a weather array
Set the Wofost parameter values
For each year to run:
Extract current year weather from weather array
Set the driving variables
For each run mode ( for example potential/water limited):
Initialize the model
Execute the model for the number of weather days
Get the summary model output
Print the simulation results
Please note that if boolean “PrintDailyDetails” is set to True in the script, the engine will print the daily values of the output variables for every simulated day. Otherwise, it is necessary to print explicitly the final output to see the simulation results. The final output contains the values of the output variables as calculated after the last time iteration.
This EcropsWofostExampleConsole console is a sample application to launch an ECroPS simulation. Overall, this code demonstrates how the model can be initialized, executed, and finalized for different run modes, and how the output of the simulation can be obtained and displayed.
The EcropsWofostExampleConsole console performs the following steps:
Initializes the WOFOST model by reading the workflow file and creating a ModelEngine object.
Gets all available run modes, as defined in the workflow file, and sets the ReturnDailyDetails and PrintDailyDetails properties of the ModelEngine object to True. If boolean “PrintDailyDetails” is set to True in the script, the engine will print the daily values of the output variables for every simulated day. Otherwise, it is necessary to print explicitly the final output to see the simulation results. The final output contains the values of the output variables as calculated after the last time iteration.
Defines basic input data for the simulation, including the year, location, crop type, and soil data.
Defines the sowing date for the crop, which is the day of the year (from 1 to 365) on which the crop is planted.
Defines the driving variables dictionary.
Reads the weather data:
Defines the firstYearInWeatherData variable, which specifies the first year in the weather data file.
Calls the ExtractWeather function, passing in the time-dependent variables, and the starting and ending dates of the simulation. The ExtractWeather function returns a subset of the weather data that corresponds to the specified year and dates.
Now, the code can use the extracted weather data to initialize and run the simulation model for the specified year.
After these initial steps, the code can use the ModelEngine object to initialize and run the WOFOST model for different run modes, and obtain the output of the simulation. This code does not contain the entire program, but only the initial setup and configuration of the WOFOST model.
The code performs the following steps for each run mode:
Initializes the model by importing the datetime module, and setting the starting and ending days of the simulation based on the specified year and duration.
Calls the initialize method of the model, passing in the weather data, driving variables, and parameters, as well as the starting and ending days of the simulation. This method returns a status object that contains the initialized state of the model.
Calls the executeStep method of the model repeatedly, passing in the status object and the current run mode. This method simulates the growth of the crop for each day of the simulation.
Calls the finalize method of the model, passing in the status object and the current run mode. This method returns the summary output of the simulation for the current run mode.
Prints the names and values of the output variables for the current run mode.
To illustrate how to read the data from a Netcdf file, the EcropsWofostExampleConsole folder contains a script called mainNetcdfWeather.py that is a variation of the main.py script. In this script, the weather data is read from a sample Netcdf file.
In the proposed example, a sample Netcdf file (weatherSample_2003.nc) contains the weather data for one year (365 days) for a grid of dimension 5 x 9. The weather is loaded into a structure called weather_matrix, having dimensions 9 x 5 x number_of_days x number_of_weather_variables. Then from the matrix the scripts reads the data of a single cell, having dimension number_of_days x number_of_weather_variables, as in the CSV example. From this point onwards, the script is identical to main.py
The provided EcropsWofostExampleConsole contains 4 sample workflow files. They can be used as examples to create other customized workflow.
the simpler workflow is in file ‘WorkflowWofostPhenology.xml’. This workflow includes the steps to simulate the WOFOST phenology model: the development stage and the phenological stage dates are calculated
the workflow in file ‘WorkflowWofostSimple.xml’ includes the steps to simulate Wofost model without taking into account the CO2 concentration. It includes the workflow of the potential simulation and the water limited (rainfed) simulation
the workflow in file ‘WorkflowWofostSimpleWithCo2.xml’, on top of the previous workflow, adds the CO2 effects on transpiration and assimilation
the workflow in file ‘WorkflowWofostCo2Partitioning.xml’, on top of the previous workflows, adds the CO2 effect on partitioning coefficients.
The ECroPS engine allow to build a graph of the workflow defined in a workflow configuration file. The graph shows the interconnections of the steps, and lists the output of a step that are used as inputs of other steps. The graph could be textual or graphical, depending on the graph builder used.
A graph builder is an implementation of the abstract class ecrops.graphbuilders.AbstractGraphBuilder.
An example implementation is provided in this package: class ecrops.graphbuilders.TextualGraphBuilder print the graph of the workflow on the console output.
Example of usage:
workflow_file = WorkflowWofostSimple.xml
runmode = 'Potential'
w = ModelEngine(workflow_file)
graphbuilders = []
graphbuilders.append(TextualGraphBuilder())
w.createModelGraph(runmode, graphbuilders)
Workflow graphs¶
In this section, we show the workflow graph of some of the model configurations.
ECroPS release notes¶
Release notes of ECroPS project Description: ECroPS (Engine for Crop Parallelizable Simulations) is a software platform to build and run agronomic models.
New in version 0.4.14
created project FPWofost
better parameters management (method getparameterslist)
New in version 0.4.14.10
added SeriesCumulator
New in version 0.4.14.14
added LayeredWaterBalance
New in version 0.4.15.7
added this release notes file :)
added PlantHeight step
added CanopyTemperature step (for now canopy temperature = max temperature)
added HeatStress step
added LinkCanopyTemperatureToHeatStress step
New in version 0.4.15.8
added the SerializeStatus/DeSerializeStatus methods in the Wofost class
New in version 0.4.16.1
classes re-organized in sub directories
New in version 0.4.17.0
automatic import of wofost steps
added dailydetails dictionary in status to host automatically daily values
New in version 0.4.18.1
modified otegui-gambin: added the calculation of yield and grain weigth after grain filling
New in version 0.4.18.2
modified otegui-gambin: added the calculation of yield and grain weigth after grain filling and translocation
New in version 0.4.18.3
modified otegui-gambin: changed some equations parameters
New in version 0.4.18.4
modified otegui-gambin: changed again some equations parameters
New in version 1.0.0.1
merged projects FPWofost and pywarm into this one. This project has now name ‘ecrops’.
Wofost class replaced by ModelEngine
namespace changed to ecrops
New in version 1.0.0.2
Layer class is no more a dictionary. So code use its properties
New in version 1.0.0.3
Changed SMO into SM0
solved bug in soil layered water balance
New in version 1.0.0.4
In ModelEngine, in the part that prints the output variables, added the condition ‘”[” in varParts[p]’ to manage output variables in form of arrays like “myvariable[3]”
New in version 1.0.0.5
Improved error log during model initialization
New in version 1.0.0.6
Improved speed by reducing the number of eval in executeStep method of ModelEngine
New in version 1.0.0.7
added version variable and ecrops_version.py file
New in version 1.0.0.8
added a check for wrong temperatures in weather class
New in version 1.0.0.9
added output variables status.rates.RFWS ,status.heatstress.DailyHeatStressFactor,status.rates.factorToIncreaseSenescenceForHeatStress
New in version 1.0.0.10
check if tavg is in input
New in version 1.0.0.11
minor fixes
New in version 1.0.1.1
added Hermes root depth
New in version 1.0.1.2
fixes for start day of classic water balance. Now starts at emergence day, not 1 day later
New in version 1.0.1.3
removed unnecessary dependencies
New in version 1.0.1.4
added first version of hermes waterbalance
New in version 1.0.1.5
fixed problem on calculation of nigth time temperature 7 days average.
New in version 1.0.2
first tentative hermens npk classes
New in version 1.0.3
in ‘leafdinamics’, row 289, we dont use the TEMP (avg temparature) variable, but we use (tmax+tmin)/2
New in version 1.1.0
many bug fixes and improvements on nitrogen hermes
New in version 1.1.1
other fixes and improvements on nitrogen hermes
New in version 1.2.0
now simulation can start before sowing date
New in version 1.2.1
other fixes for nitrogen
New in version 1.2.2
fix for layered water balance: corrected a bug where the loss to subsoil water was removed twice from last layer water
New in version 1.3.0
mystatus now called status. timedependantvariable now called timedependantvariables. added arguments first_day, simulation_start_day,
simulation_end_day
New in version 1.3.1
added hermes root depth in layered water balance
New in version 1.3.2 -removed unused steps. Added code documentation in subfolder docs. Improved code comments
New in version 1.4.1
added DrivingVariables section in workflow file
New in version 1.4.2
added debug_timing_mode, added WeatherColumnForVariable setting
New in version 1.4.3
fixed nitrogen qrez calculation parameters - fixed START_MODE initialization of phenology
New in version 1.4.4
initialization of leaves, roots, stems and storage organs moved from integrate to runstep methods. Avoid calling nitgth temperature (TMINRA) calculation twice the first simulated day
New in version 1.5.0
added configuration boolean PrintDailyDetailsToFile
added configuration boolean ReturnDekadalDetails
added management of soil water calculation before sowing
Added rounding in afgen results
returns the daily details array if ReturnDailyDetails is True
returns the dekadal details array if ReturnDekadalDetails is True
update in Wofost components copyright info
New in version 1.5.1
fix for crops having AMAXTB(2)=0, to make it similar to bioma. Class WOFOST_Assimilation line 260
New in version 1.5.2
refactoring of FPWarm model - in HeatStress added the “Sum of the damages” case - changed daily details behaviour - added WARM cold sterility
New in version 1.5.4
small fixes
New in version 1.5.6
better implementation of different start type of soil water simulation in LayeredWaterBalance
New in version 1.5.7
in Weather step, added checks to verify the weather variable are not NaN
New in version 1.5.8
added SOIL_TEMPERATURE in Weather step, added a check to verify WeatherArray is present. Removed unused SeriesCumulator step. Removed rounding from Afgen call method
New in version 1.6.1
added methods ‘getinputslist’ and ‘getoutputslist’ to the steps
added the AbstractGraphBuilder and TextualGraphBuilder classes
added method createModelGraph in ModelEngine, added class ModelWorkflowReader
new in version 1.7.0
added the ecrops.Step abstract class that all the steps should implement. Added the AbstractGraphBuilder class and the mechanism to build workflow graphs